I'm actually against this: if I'm not mistaken this feature is already supported via visitor plugins (I can't test it right now, but I suspect it's about 20-40 lines of code to map at-rule visitor function to a set of custom functions). So... should not we just write a documentation and/or provide a template for such plugin instead of creating yet another plugin format?

@seven-phases-max It isn't another plugin format. Plugins are declared the same way. It's just allowing the @-rule as a stand-in for replacement, with the arguments sent to JS, just like custom functions do. It behaves the same, where @-rules / functions pass through unchanged if they don't match a registered function. The only difference is that the arguments are always the same.

That said.... offering plugin templates for specific types of use cases is not unreasonable. I've actually been working on a "universal" plugin template for Less. That is, one that can unify the two separate plugin formats and be loaded either way. Currently, both formats are mutually incompatible, and even have opposite program flows (plugin A "attaches" itself to Less, plugin B gets attached by Less). Buuuuut there may be a way to bridge the gap.

Oh, now I remember the justification for this over some kind of visitor plugin. You can't currently call the latter with @plugin, making not just the library author's job harder, but also for the end user consuming the plugin. Buuuuut... I suppose if I can find a way to tweak the @plugin call to allow you to add a visitor or do whatever else you want to do (which would have probably been ideal in the first place, oh well), maybe it could get there? Because I get your skepticism of the function call part. It's just something I was drooling over as a Less library author.

And...... presuming we have some sort of "advanced usage" that lists said plugin template for adding a custom @-rule, isn't it a distinction without a difference from having an advanced usage that demonstrates how to make a custom @-rule call something in a plugin? Either way would end up adding something to the core codebase to make possible, except that the method in this PR is easier for someone to actually do.

What if I focus on this:

1. Aligning "Plugin A and B" behavior, meaning perhaps that any plugin can be written and called via @plugin.
2. Make visitors easier to define via plugins.
3. Test that approach to demonstrate the same use case.

That might be better anyway because it focuses on making some of the core pieces easier to use, rather than adding something to functions. Sound better?

Yes, otherwise if accepted, this justification would literally mean "abandon plugins" (except functions, but "easy functions" were not really the only and the main goal of all those efforts). I've put additional details on "plugin unification" at #17.

Closing this pull request per discussion.